ETSITS123 091 v3.2.o 



(2000-10) 



Technical Specification 



Digital cellular telecommunications system (Phase 2+) (GSM); 

Universal Mobile Telecommunications System (UMTS); 

Explicit Call Transfer (ECT) supplementary service - Stage 2 

(3GPP TS 23.091 version 3.2.0 Release 1999) 



35^ 



G5 




® 



GLOBAL SYSTEM FOR 
MOBILE COMMUNICATIONS 




3GPP TS 23.091 version 3.2.0 Release 1999 1 ETSI TS 123 091 V3.2.0 (2000-10) 



Reference 



RTS/TSGN-SS23091UR1 
Keywords 



GSM, UMTS 



ETSI 

650 Route des Lucioles 
F-Q6921 Sophia Antipolis Cedex - FRANCE 

Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 1 6 

Siret N°348 623 562 00017 - NAF 742 C 
Association a but non lucratif enregistree a la 
Sous-Prefecture de Grasse (06) N° 7803/88 



Important notice 



Individual copies of the present document can be downloaded from: 
http://www.etsi.orq 

The present document may be made available in more than one electronic version or in print. In any case of existing or 

perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). 

In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive 

within ETSI Secretariat. 

Users of the present document should be aware that the document may be subject to revision or change of status. 
Information on the current status of this and other ETSI documents is available at http://www.etsi.orq/tb/status/ 

If you find errors in the present document, send your comment to: 
editor@etsi.fr 

Copyright Notification 

No part may be reproduced except as authorized by written permission. 
The copyright and the foregoing restriction extend to reproduction in all media. 

© European Telecommunications Standards Institute 2000. 
All rights reserved. 



ETSI 



3G PP TS 23.091 version 3.2.0 Release 1 999 2 ETSI TS 1 23 091 V3.2.0 (2000-1 0) 



Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server (http://www.etsi.org/ipr) . 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 3 14 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by the ETSI 3"^^ Generation Partnership Project (3GPP). 

The present document may refer to technical specifications or reports using their 3GPP identities, UMTS identities or 
GSM identities. These should be interpreted as being references to the corresponding ETSI dehverables. 

The cross reference between GSM, UMTS, 3GPP and ETSI identities can be found under www.etsi.org/key . 



ETSI 



3GPP TS 23.091 version 3.2.0 Release 1999 3 ETSI TS 123 091 V3.2.0 (2000-10) 



Contents 



Foreword 4 

1 Scope 5 

2 References 5 

3 Definitions and abbreviations 5 

3.1 Definitions 5 

3.2 Abbreviations 6 

4 Explicit Call Transfer (ECT) 6 

4.1 Functions 6 

4.2 Overall SDL-diagrams and information flows 8 

4.2.1 General description 8 

4.2.2 ECT (both calls answered) 8 

4.2.3 ECT (one call answered, the other alerting) 13 

4.3 Interaction with other supplementary services 17 

4.3.1 Line Identification services 17 

4.3.2 Call Forwarding Unconditional (CFU) 19 

4.3.3 Call Forwarding on mobile subscriber Busy (CFB) 20 

4.3.3.1 Call Forwarding on mobile subscriber Busy due to Network Determined User Busy (NDUB) 20 

4.3.3.2 Call Forwarding on mobile subscriber Busy due to User Determined User Busy (UDUB) 20 

4.3.4 Call Forwarding on No Reply (CFNRy) 21 

4.3.5 Call Forwarding on mobile subscriber Not Reachable (CFNRc) 21 

4.3.6 Call Waiting (CW) 21 

4.3.7 Call Hold (HOLD) 21 

4.3.8 Multi Party (MPTY) 21 

4.3.9 Closed User Group (CUG) 21 

4.3.10 Advice of Charge (AoC) services 22 

4.3.11 Call Barring services 22 

4.3.12 Explicit Call Transfer (ECT) 22 

4.4 Information stored in the HLR 22 

4.5 State transition model 22 

4.6 Transfer of information from the HLR to the VLR 23 

4.7 Information stored in the VLR 23 

4.8 Handover 23 

Annex A: Change history 24 



ETSI 



3GPP TS 23.091 version 3.2.0 Release 1999 4 ETSI TS 123 091 V3.2.0 (2000-10) 



Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3 GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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1 Scope 

The present document gives the stage 2 description of the call transfer supplementary services. 

Only one call transfer supplementary service has been defined, this is the Explicit Call Transfer (ECT) supplementary 
service, and is described in the present document. 

2 References 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. 
[1] TR 21.905: "3G Vocabulary". 

[2] TS 23.083: "Call Waiting (CW) and Call Hold (HOLD) supplementary services - Stage 2". 

[3] TS 24.008: "Mobile radio interface layer 3 specification; Core Network Protocols - Stage 3". 

[4] T/S 22-21 (version 9): "Integrated Services Digital network (ISDN); ExpHcit Call Transfer (ECT) 

supplementary service; Functional capabilities and information flows". 

[5] DE/SPS-6001.22 (version 9): "Integrated Services Digital network (ISDN); ExpHcit Call Transfer 

(ECT) supplementary service; Signalling System No. 7; Integrated services digital network User 
Part (ISUP) protocol". 

3 Definitions and abbreviations 
3.1 Definitions 

First call: One of the subscriber A calls (answered). 

Notification Indicator (NI): Indicates to each remote party in which state of the other remote party ECT was 
performed (active, alerting). 

Redirection Number (Rdn): Includes the presentation indicator and the directory number of the other remote party. 

Second call: The other subscriber A call (answered or alerting). 

Subscriber A (PARTY A): The served mobile subscriber - the one who has subscribed to, and invokes the ECT 
Supplementary Service. 

Subscriber B (PARTY B): The other party in the subscriber A first call. 

Subscriber C (PARTY C): The other party in the subscriber A second call. 

Subscriber D (PARTY D): The forwarded-to party when the call is forwarded by the subscriber C. 

Transferred call: The resulting call after successful explicit call transfer between B and C. 
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3.2 Abbreviations 

In addition to those below, abbreviations used in the present document are Hsted in TR 21.905. 

ECT: ExpHcit Call Transfer supplementary service 

LI: Line Identity 

NI: Notification Indicator 

Rdn: Redirection number 

RdnB : Redirection number of the party B 

RdnD: Redirection number of the party D 



Explicit Call Transfer (ECT) 



4.1 Functions 

The following function has been identified for the explicit call transfer service: 

MAFQ27 

Explicit Call Transfer related authorizations examination 

The ability of a PLMN component to determine the authorizations relating to explicit call transfer. See figure 
L 

Location: VLR 

Within the authorization examinations diagram, the messages shown to and from the left are to and from the MSC. 

After receiving a "invoke ECT request" the VLR will check if the Explicit Call Transfer service is provisioned for the 
served subscriber. If the service is provisioned the VLR send back to the MSC "Explicit Call Transfer available". If the 
service is not provisioned the VLR will send back to the MSC "Explicit Call Transfer not available". When the response 
has been sent back to the MSC the process will return to the idle state. 
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Figure 1 : Explicit Call Transfer related authorizations examination (VLR) 
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4.2 Overall SDL-diagrams and information flows 
4.2.1 General description 

The overall SDL-diagrams represent the network as a whole. The overall SDL-diagrams show the status of the service 
as perceived by the served mobile subscriber, as well as the status as perceived by any of the other parties. Besides this, 
the overall SDL-diagrams show the actions to be taken by the network and the information provided by the network to 
the users. 

Within the overall SDL-diagrams, messages to and from the served mobile subscriber are indicated to and from the left, 
whereas messages to and from remote parties are indicated to and from the right. 

The following states for the invocation of the ECT supplementary service are defined: 

a) First Call (Active, Held), Second Call (Active, Idle); 

b) Second Call (Active, Held), First Call (Active, Idle); 

c) First Call (Active, Held), Second Call (Call DeHvered, Idle). 

These two dimensional states are also used in the SDLs and information flows: 

- the first dimension is a normal basic call state "active" or "call delivered"; 

- the second dimension is "held" meaning that the call is set on hold. 

NOTE: The call state "call delivered" means that a ALERT message has been received in the MS, but no 
ANSWER MESSAGE (ANM) is received. 

In the information, flows it is assumed that the served subscriber is a mobile subscriber and that the other parties are 
mobile or fixed subscribers. 

Party A is the subscriber controlling the Explicit Call Transfer Call (served mobile subscriber). Party B is the first 
remote party called. Party C is the second remote party called. 

The served party is disconnected by the generic disconnect/release procedure after a successful transfer request. The 
connection of the remote party calls in a new call (transferred call) is located in the MSC. 

The first figures of the information flows (figures 4 and 7) show the unsuccessful case of the transfer request (check in 
the VLR or in the MSC fails). 

The second figures (figures 5 and 8) show the successful case of the transfer request. 



4.2.2 ECT (both calls answered) 



After receipt of a ECT request from the served subscriber, the MSCA^LR will check if the Explicit Call Transfer 
supplementary service is provisioned for the served subscriber (see also MAF027). 

If the ECT Supplementary Service is provisioned, then the MSCA^LR will check if the transfer is barred by virtue of 
call states or supplementary service interactions (see also figure 3 and subclause 4.3). 

If there are no such barring causes then the MSCA^LR also checks if CUG restrictions are infringed (see also figure 3 
and subclause 4.3). 

If the outcome of these checks are successful and the loop prevention option is supported, an endless loop prevention 
check shall be performed according to T/S 22-21 (version 9) and DE/SPS600L22 (version 9). 

If the result of this check is also successful the both calls shall be connected in the MSC (without including the served 
subscriber in this connection), the held party will be retrieved and both remote parties will be notified that call transfer 
was done. 

With this notification the both subscribers will be informed about the state of the other remote party in which call 
transfer was done ("call transferred, active") and if possible about the identity (Redirection number) of each other (for 
details see also subclause 4.3). 
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After that the served mobile subscriber will be disconnected from both calls. 

If the checks fail the ECT request will be rejected and the two calls remain in the call states in which they were before 
ECT was attempted. 

The overall SDL for Explicit Call Transfer (both calls are answered) is shown in figure 2. 

The checks if Explicit Call Transfer is barred or not are shown in figure 3. 

The corresponding information flows are given in figure 4 and figure 5. 
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Figure 2: Overall SDL-diagram of Explicit Call Transfer (both calls answered) 
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4.2.3 ECT (one call answered, the other alerting) 

In this case, generally the same procedures will apply as in the other case (both calls answered). The same checks shall 
be performed and if all checks are fulfilled both calls shall be connected together (without including the served 
subscriber in this connection). After the connection of the both calls, both subscriber (B and C) will be notified about 
the call transfer invocation in the same way as in the case where the two calls are answered. 

The transfer notification to the subscriber B will include the information that the transfer was done in the altering state 
of subscriber C ("call transferred, alerting"). After receipt of the answer message from subscriber C, the subscriber B 
will be notified again, indicating that answer has taken place subsequent to the alerting transfer ("call transferred, 
active"). 

The overall SDL for Explicit Call Transfer (one call answered, the other alerting) is shown in figure 6. 

The corresponding information flows are given in figure 7 and figure 8. 
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4.3 Interaction with other supplementary services 
4.3.1 Line Identification services 

Tables 1 to 4 indicate the information to be provided in the Notification Indicator (NI) and the Redirection Number 
(Rdn) when the subscribers B and C are notified. Call states refer to the situation before ECT invocation. At that time 
one of the calls is on hold. 

If user B was the called subscriber in the call A-B, table 1 applies to the information supplied to subscriber C. If user B 
was the calling subscriber in the call A-B, table 2 applies to the information supplied to subscriber C. 

Mobile subscriber A has an active call to subscriber B and: 

- puts the active call on hold and calls subscriber C, table 3 applies to the information supplied to subscriber B; 

- receives and accepts a call from subscriber C (by putting B on Hold), table 4 applies to the information supplied 
to subscriber B. 
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Table 1 : Mobile subscriber A was calling subscriber B, puts B on hold and calls subscriber C 



Call states 


COLR indication received from 
subscribers B's network 


Information provided to C 


A-B Active 

A-C Active / Alerting 


Indicated "allowed" 


At time of transfer: 

Nl: "call transferred, active" 

Rdn: PI = allowed, LI of B 


A-B Active 

A-C Active / Alerting 


Indicated "restricted" 


At time of transfer: 

Nl: "call transferred, active" 

Rdn: PI = restricted (note 1) 


A-B Active 

A-C Active / Alerting 


No indication received 
(e.g. interworking) 


At time of transfer: 

Nl: "call transferred, active" 

Rdn: PI = not available 



Table 2: Mobile subscriber A was called by subscriber B, puts B on hold and calls subscriber C 



Call states 


CLIR indication received from 
subscribers B's network 


Information provided to C 


A-B Active 


Indicated "allowed" 


At time of transfer: 


A-C Active / Alerting 




Nl: "call transferred, active" 
Rdn: PI = allowed, LI of B 


A-B Active 


Indicated "restricted" 


At time of transfer: 


A-C Active / Alerting 




Nl: "call transferred, active" 
Rdn: PI = restricted (note 1) 


A-B Active 


No indication received 


At time of transfer: 


A-C Active / Alerting 


(e.g. interworking) 


Nl: "call transferred, active" 
Rdn: PI = not available 



NOTE 1 : If the subscriber C has CLIP Override Category then the following information is carried in the 
Redirection number: PI = restricted, LI of B. 
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Table 3: Mobile subscriber A puts the call to B on hold and calls subscriber C 



Call states 


COLR indication received from 
subscribers C's network 


Information provided to B 


A-B Active 
A-C Active 


Indicated "allowed" 


At time of transfer: 

Nl: "call transferred, active" 

Rdn: PI = allowed, LI of C 


A-B Active 
A-C Active' 


Indicated "restricted" 


At time of transfer: 

Nl: "call transferred, active" 

Rdn: PI = restricted (note 2) 


A-B Active 
A-C Active 


No indication received 
(e.g. interworking) 


At time of transfer: 

Nl: "call transferred, active" 

Rdn: PI = not available 


A-B Active 
A-C Alerting 


Indicated "allowed" at receipt of 
CONNECT by subscriber C 


At time of transfer: 
Nl: "call transferred, alerting" 
At subscribers C CONNECT: 
Nl: "call transferred, active" 
Rdn: PI = allowed, LI of C 


A-B Active 
A-C Alerting 


Indicated "restricted" at receipt of 
CONNECT by subscriber C 


At time of transfer: 
Nl: "call transferred, alerting" 
At subscribers C CONNECT: 
Nl: "call transferred, active" 
Rdn: PI = restricted (note 2) 


A-B Active 
A-C Alerting 


No indication received at receipt of 
CONNECT by subscriber C 
(e.g. interworking) 


At time of transfer: 
Nl: "call transferred, alerting" 
At subscribers C CONNECT: 
Nl: "call transferred, active" 
Rdn: PI = not available 



Table 4: Mobile subscriber A was called by subscriber C and accepts the call by putting subscriber B 

on hold 



Call states 


CLIR indication received from 
subscriber C's network 


Information provided to B 


A-B Active 
A-C Active 


Indicated "allowed" 


At time of transfer: 

Nl: "call transferred, active" 

Rdn: PI = allowed, LI of C 


A-B Active 
A-C Active 


Indicated "restricted" 


At time of transfer: 

Nl: "call transferred, active" 

Rdn: PI = restricted (note 2) 


A-B Active 
A-C Active 


No indication received 
(e.g. interworking) 


At time of transfer: 

Nl: "call transferred, active" 

Rdn: PI = not available 



NOTE 2: If the subscriber B was called by subscriber A and has CLIP Override Category, or if subscriber B called 
subscriber A and has COLP Override Category then the following information is carried in the 
Redirection number: PI = restricted, LI of C 

4.3.2 Call Forwarding Unconditional (CFU) 

No impact. 
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4.3.3 Call Forwarding on mobile subscriber Busy (CFB) 



4.3.3.1 



No impact. 



Call Forwarding on mobile subscriber Busy due to Network Determined User 
Busy (NDUB) 



4.3.3.2 Call Forwarding on mobile subscriber Busy due to User Determined User 

Busy (UDUB) 

When subscriber A transfers the forwarded call there is no impact. 

When subscriber C forwards the transferred call to the forwarded-to subscriber D due to UDUB the line identity 
information of the subscriber B that was received by the subscriber C in the ECT invocation notification shall be sent as 
calling line identity to the forwarded-to subscriber D instead of the line identity of the subscriber A. The corresponding 
information flow is given in figure 9. For the line identity information sent to the subscriber B after the call is answered 
by the forwarded-to subscriber D the table 5 applies. 



MSa MSCa VLRa MSCb 

A-B (active, held) / A-C (call delivered, idle) 



ECT request 



|0R1:Y 
connect calls 



ECT ack 



disc req A- 



disc req A-C 



info request 



info ack 



I 
I 

MAF027 

I 
I 
I 
I 
I 
I 



notification (retrieve) 
> 

I I 

notification (ECT) 

> 

(alerting) 

I I 

notification (ECT) 



(active, RdnB) 

I I 

I I 

I I 

I I 

I I 

I I 

I I 

I I 

I I 

I I 

I I 



I I 

notification (ECT) 
(active, RdnD) 

I I 
I I 



notification 

> 

(retrieve) 

notification (ECT) 



(alerting) 



ANSWER (LI=D) 



notification (ECT) 



(active, RdnD) 



notification (ECT) 

> I 

(active, RdnB) | 

I 

reject (UDUB) | 

< 1 



I 

set up (LI=RdnB 




MSCd MSd 

I I 

I I 

I I 

I I 

I I 

I I 

I I 

I I 

I I 

I I 

I I 

I I 

I I 

I I 

I I 

I I 

I I 

I I 

I I 

I I 

I I 

I I 

I I 

I I 

I I 

I I 

I I 

I I 

I I 

setup 

l->l 

I I 

connect 

l<-l 

I I 

con ack 

l->l 

I I 

I I 

I I 

I I 



NOTE: ORl : Checks in VLR and MSC ok? (Y: yes N: no) 

Figure 9: Information flow for interaction of explicit call transfer (one call answered, the other alerting) with 

forwarding 



call 
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Table 5: Subscriber C forwards the transferred call to the subscriber D 



Call states 


COLR indication received from 
subscribers D's network 


Information provided to B 


A-B Active 


Indicated "allowed" at receipt of 


At time of transfer: 


A-C Alerting, 


CONNECT by subscriber D 


Nl: "call transferred, alerting" 


forwarded to D 




At subscribers D CONNECT: 
Nl: "call transferred, active" 
Rdn: PI = allowed, LI of D 


A-B Active 


Indicated "restricted" at receipt of 


At time of transfer: 


A-C Alerting, 


CONNECT by subscriber D 


Nl: "call transferred, alerting" 


forwarded to D 




At subscribers D CONNECT: 
Nl: "call transferred, active" 
Rdn: PI = restricted (note 1) 


A-B Active 


No indication received at receipt of 


At time of transfer: 


A-C Alerting, 


CONNECT by subscriber D 


Nl: "call transferred, alerting" 


forwarded to D 


(e.g. interworking) 


At subscribers D CONNECT: 
Nl: "call transferred, active" 
Rdn: PI = not available 



NOTE 1 : If the subscriber B was called by subscriber A and has CLIP Override Category, or if subscriber B called 
subscriber A and has COLP Override Category then the following information is carried in the 
Redirection number: PI = restricted, LI of D. 

4.3.4 Call Forwarding on No Reply (CFNRy) 

Same as the interaction between call forwarding on mobile subscriber busy due to UDUB and explicit call transfer as 
described in subclause 4.3.3.2. 

Figure 9 applies except that call forwarding is invoked by the CFNRy timer expiry instead of reception of reject 
(UDUB) message. 

For the line identity information sent to the subscriber B after the call is answered by the forwarded-to subscriber D the 
table 5 applies. 

4.3.5 Call Forwarding on mobile subscriber Not Reachable (CFNRc) 

No impact. 

4.3.6 Call Waiting (CW) 

No impact. 

4.3.7 Call Hold (HOLD) 

No impact. 

4.3.8 Multi Party (MPTY) 

The MSCA^LR shall reject any ECT request from the served subscriber of a MPTY call. 

4.3.9 Closed User Group (CUG) 

Closed user group restrictions shall be met between users when the first call is set up. 

Similarly, closed user group restrictions shall also be met between users when setting up the second call. 

Finally, for successful explicit call transfer the served mobile subscriber must use the same CUG-Interlock code for 
both calls. The same rule shall applied regardless of being two MO calls, two MT calls or one MO and one MT call. 
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4.3.10 Advice of Charge (AoC) services 

No impact. 

4.3.1 1 Call Barring services 

No impact 

4.3.1 2 Explicit Call Transfer (ECT) 

It is required as a network option that the estabHshment of endless loops between subscriber A and subscriber B, both of 
them transferring the call to the other one, is prevented. The same loop prevention mechanism as in ISDN shall be used. 



4.4 



Information stored in the HLR 



The following logical states are applicable for the Explicit Call Transfer service (refer to GSM 03.1 1 for an explanation 
of the notation): 



Provisioning State 

(Not Provisioned, 
(Provisioned, 



Registration State 

Not Applicable, 
Not Applicable, 



Activation State 



HLR Induction State 



Not Active, Not Induced) 

Active and Operative, Not Induced) 



The HLR shall store the logical state of the Explicit Call Transfer service (which shall be one of the valid states listed 
above) on a per subscriber basis. 



4.5 



State transition model 



Figure 10 shows the successful cases of transition between the applicable logical states of the Explicit Call Transfer 
service. The state changes are caused by actions of the service provider. 

Note that error cases are not shown in the diagram as they normally do not cause a state change. Additionally, some 
successful requests may not cause a state change and are therefore not shown in the diagram. 

Provision 



(Not Provisioned, 

Not Applicable, 

Not Active, 

Not Induced) 




(Provisioned, 

Not Applicable, 

Active and Operative, 

Not Induced) 



Withdra\A/al 
Figure 10: State transition model 
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4.6 Transfer of information from the HLR to tine VLR 

If the provisioning state for the ExpHcit Call Transfer service is "Provisioned" then when the subscriber registers on a 
VLR the HLR shall send that VLR information about the logical state of the Explicit Call Transfer service. 

If the logical state of the Explicit Call Transfer service is changed while a subscriber is registered on a VLR then the 
HLR shall inform the VLR of the new logical state of the Explicit Call Transfer service. 

4.7 Information stored in tine VLR 

For the supplementary service Explicit Call Transfer the VLR shall store the service state information received from the 
HLR. 

4.8 Handover 

Handover will have no impact on the control procedures and the operation of the service. 
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